1. Field of the Invention
The present invention relates to information communication systems, information communication apparatuses and methods, and computer programs therefor for transmitting information content to be protected by copyright over Internet protocol (IP) networks. In particular, the present invention relates to information communication systems, information communication apparatuses and methods, and computer programs therefor for transmitting IP packets over IP networks with a limited number of router hops.
More specifically, the present invention relates to an information communication system, an information communication apparatus and method, and a computer program therefor for performing an authentication and key exchange (AKE) procedure in accordance with the Digital Transmission Content Protection over Internet Protocol (DTCP-IP) standard between information devices over an IP network. In particular, the present invention relates to an information communication system, an information communication apparatus and method, and a computer program therefor for transmitting and receiving AKE commands for authentication and key exchange between devices over an IP network with a limited number of router hops.
2. Description of the Related Art
Recently, content distribution and delivery services for providing content, such as video and music, over networks have increasingly being performed. Such services allow content distribution to be carried out between remote terminals over a network without the need to move media such as compact disks (CDs) and digital versatile disks (DVDs).
Content to be handled over networks is protected under copyright laws as one of copyrighted works against unauthorized use such as unauthorized copying or tampering. In the Copyright Law of Japan, the reproduction of a work by a user him/herself for the purpose of his/her personal or home use would be permitted under Article 30, whereas, the use of copies of a work for purposes other than the personal or private use would be prohibited under Article 49 (1).
Since such content is digital data and is vulnerable to unauthorized access and modification such as copying and tampering, there is a demand for protection against unauthorized use in view of not only legal but also technical solutions.
Therefore, a number of technologies for the purpose of copyright protection against unauthorized use of digital content have been developed. For example, the Digital Transmission Content Protection (DTCP) standard, which is an industry standard for protecting digital transmission content, defines a mechanism for content transmission in a copyright-protected environment (see, for example, DTCP Specification Volume 1 Revision 1.4 (Informational Version), which is available from http://www.dtcp.com).
In DTCP, a protocol for authentication between devices for content transmission and a protocol for transmission of encrypted content are specified. In summary, the specification defines that a DTCP-compliant device should not send any easy-to-use, compressed content, such as MPEG (Moving Picture Experts Group) content, to outside the device in the unencrypted form, that key exchange necessary for decryption of encrypted content should be carried out according to a predetermined authentication and key exchange (AKE) algorithm, and that the range of devices through which key exchange is performed using AKE commands should be limited.
A content provider, or a server (DTCP source), and a content consumer, or a client (DTCP sink), share a key through an authentication procedure by sending and receiving AKE commands. The key is used to encrypt a transmission line to perform content transmission. An unauthorized client could not obtain a cryptographic key unless it has successfully been authenticated with the server, and thus could not receive the content. Further, by limiting the number and range of devices that transmit and receive AKE commands, the use of the content can be limited to personal or home use, as defined by copyright law.
Initially, DTCP defines transmission of digital content over a home network using a transmission line such as IEEE 1394. Transmission of content over the home network falls within personal or home use, as defined by copyright law.
Recently, the development of a sophisticated technology, called DTCP-IP, in which IEEE-1394-based DTCP technology is incorporated into IP network technology has advanced. Since most home networks are connected via routers to external wide area networks such as the Internet, the establishment of DTCP-IP technology provides flexible and efficient use of digital content over an IP network while protecting the content. Although DTCP-IP technology is fundamentally involved in the DTCP standard, DTCP-IP technology is different from the original, IEEE-1394-based DTCP technology in that an IP network is used as a transmission line and that encrypted content is transmitted using the HTTP or RTP protocol.
IP (Internet Protocol) itself is a network layer in which an incoming data stream from an upper transport layer, such as TCP (Transmission Control Protocol), is divided by a packet size used as a predetermined unit into packets to produce IP packets by adding headers to the packets, and the IP packets are delivered to a specified IP address. IP has a routing function (see, for example, RFC (Request For Comment) 791 INTERNET PROTOCOL).
Since a variety of devices, such as personal computers (PCs), are connected to the IP network, there is a high risk of eavesdropping or tampering of data. Therefore, DTCP-IP further specifies a method for transmission of content over the network while protecting the content although it is fundamentally a DTCP-resembling technology in which DTCP technology is incorporated into IP network technology (see, for example, DTCP Specification Volume 1 Supplement E Mapping DTCP to IP, Revision 1.1 (Informational Version), which is available from http://www.dtcp.com/).
A content transmission procedure according to DTCP-IP will be described. DTCP-compliant devices are classified into two types, i.e., one referred to as “DTCP_Source” and the other as “DTCP_Sink”. A DTCP_Source device serving as a server device receives a request for content, and transmits the content. A DTCP_Sink device serving as a client device requests content, receives the content, and plays back or records the content.
First, the DTCP_Source device and the DTCP_Sink device establish a single TCP/IP connection, and authenticate each other. This authentication is referred to as a “DTCP authentication” or an “AKE (Authentication and Key Exchange)”. A DTCP-compliant device has a unique device ID and key embedded therein by a certification organization called DTLA (Digital Transmission Licensing Administrator). In the DTCP authentication procedure, after the DTCP_Source device and the DTCP_Sink device use such information to verify that they are authorized DTCP-compliant devices, a key for encrypting or decrypting content, which is managed by the DTCP_Source device, can be shared between the DTCP_Source device and the DTCP_Sink device.
After performing the AKE-based authentication procedure between the DTCP-compliant devices, the DTCP_Sink device requests content on the DTCP_Source device. The DTCP_Source device can notify in advance the DTCP_Sink device of the content location for accessing the content on the DTCP_Source device via a content directory service (CDS) or the like. The DTCP_Sink device may use a protocol, such as HTTP (Hyper Text Transfer Protocol) or RTP (Real Time Protocol), to request the content. When the content is requested according to the HTTP procedure, the DTCP_Source device serves as an HTTP server and the DTCP_Sink device serves as an HTTP client, between which the transmission of the content is initiated. When an RTP-based transmission is requested, the DTCP_Source device serves as an RTP sender and the DTCP_Sink device serves as an RTP receiver, between which the transmission of the content is initiated. Other transmission protocols, such as RSTP (Real Time Streaming Protocol), may also be adopted.
When content transmission is performed according to HTTP, the HTTP client creates a TCP/IP connection for HTTP, which is different from the TCP/IP connection for the DTCP authentication. The HTTP client requests content on the HTTP server according to a similar operation procedure to the standard HTTP procedure. In response to the request, the HTTP server returns the requested content as an HTTP response. The data transmitted as the HTTP response is data into which the HTTP server, i.e., the DTCP_Source device, encrypts the content using the key shared through the AKE authentication. Upon receiving the encrypted data, the client (DTCP_Sink device) decrypts the data using the key shared through the above-described authentication to play back or record the content.
Accordingly, DTCP-IP can provide a secure content transmission protocol even over an IP network, which enables the content to be protected against eavesdropping or tampering in the middle of the transmission line by performing authentication between DTCP-compliant devices to share a key between the DTCP-authenticated devices and encrypting and decrypting transmission content.
DTCP involves not only the maintenance of the security of content transmission lines by encrypting them but also the limitation of the use of the content to personal or home use, as defined by copyright law. The initial DTCP technology assumes home networks, such as IEEE-1394-based networks, in which case the use of content is substantially limited to personal or home use. In DTCP-IP, which is a DTCP-resembling technology in which DTCP technology is incorporated into IP network technology, however, since devices can be connected to a wide area IP network, such as the Internet, via routers, there is a demand for limitation on the content transmission range.
For example, in the IP network, a parameter called Time-To-Live (TTL) is defined in the header of each IP packet in order to limit the lifetime of the IP packet (for example, see RFC (Request For Comment) 791 INTERNET PROTOCOL). An IP router decrements the TTL field value in the header whenever forwarding the IP packet (for example, see RFC 1812—Requirements for IP Version 4 Routers June 1995) so that the lifetime or expiration time of the IP packet can be represented by the TTL field value (for example, see PCT Japanese Translation Patent Publication No. 2003-521138).
In DTCP-IP, for example, a TTL field value of “3” is set, and each IP packet is checked as to whether or not the TTL field value does not exceed 3. That is, the number of router hops between the user and the other party between which the transmission and reception of AKE commands, i.e., key exchange, is carried out is limited to 3 or less (see, for example, DTCP Specification Volume 1 Supplement E Mapping DTCP to IP, Revision 1.1 (Informational Version), which is available from http://www.dtcp.com/), thereby limiting the use of content to personal or home use.
However, there are some technical problems when the DTCP application implements processing, such as obtaining and checking header information, such as TTL, of IP packets. These technical problems will be described.
As well known in the art, a communication protocol has a stack of protocols, such as TCP and IP, and the application layer is defined as the highest layer.
The existing IP protocol layer implements only the function of decrementing the TTL field value by 1 each time an IP packet passes through a router. In other words, the IP protocol layer is not configured so as to, upon receiving an IP packet, extract the TTL field value from the header of the IP packet and to notify the high application layer. This prevents the DTCP application, upon receiving an AKE command, from checking whether or not the TTL field value of the IP packet is 3 or less.
Although the existing IP protocol has a function for discarding an IP packet whose TTL field value has expired due to multiple routers hops, an IP packet whose TTL field value exceeds a predetermined value is not discarded. If a transmission destination of an AKE command checks the header of the IP packet and discards the IP packet when the TTL field value exceeds 3, a transmission source of the AKE command performs a time-consuming process for re-transmitting the AKE command because of the TCP/IP typical re-transmission control function.
One method for implementing the operation of limiting the range where an AKE command reaches using the TTL field value that is decremented by the router each time a hop occurs according to the DTCP-IP specification is to modify the IP protocol layer. However, it is costly to develop uniquely all processing modules in the TCP/IP protocol layer incorporating the function of obtaining and checking TTL field values.
In most of the current mainstream operating systems (OSs), such as Linux or Windows, which is a registered trademark of Microsoft Corporation, a protocol stack for communication, such as TCP and IP, is installed in the OS. If the IP protocol is modified, the source code deeply related to the OS will be modified, which causes various demerits.
For example, in the case of OSs whose source code has not been released, such as Windows®, the modification itself is almost impossible.
In the case of so-called open-source OSs, such as Linux, since the source code is available to the public, individuals are able to add the above-described functions of the IP protocol layer. In return, the individuals are obliged to release the source code because all relevant codes are licensed under GPL (General Public License). That is, the modification of open-source products makes it time-consuming for the developers to manage the products in the future. Further, the modification of the kernel source code deeply related to the core of the OS involves an additional test process, leading to an increase in cost.
An OS further has installed therein a network filter as a function of the processing module in the TCP/IP protocol layer. In Linux, “iptable” is an example of such a network filter. By setting this standard network filter, the processing for obtaining and checking TTL field values can be implemented using the existing TCP/IP processing module.
Problems with the use of the network filter are that (1) the set network filter can induce a side effect of impeding other communication (or services) and (2) the set network filter can be easily tampered with by any other user or process since the network filter is standard.
It is also conceived by those skilled in the art that a processing module corresponding to a network filter is uniquely developed and is used to obtain and check TTL field values. However, the development imposes significant cost, and the set network filter can induce a side effect of impeding other communication (or services).